A hosted application is an application that runs on a server that multiple user devices have shared access to over a network. As used herein, the term “application program” refers to a computer program, or group of programs, that configures a computer to perform functions directly for a user of the application. This is in contrast to system programs, which typically provide one or more software program infrastructure layers, such as an operating system, utilities and related components that manage and integrate a computer's capabilities to serve an application program, which in turn, serves the user. A Browser may act as an interface between a hosted application and a user device, for example. Hosted applications may include client and server components in which a client that runs directly on a client user device communicates over a network with a hosted component that runs on a server. A downloadable application, sometimes referred to as an “App,” for example, may act as client interface between a hosted application and a client user device. Hosted applications may run on dedicated servers owned and operated by an individual organization. Alternatively, hosted applications may run on a so called cloud computing platform in which servers are virtualized and hardware and software compute resources are shared by other hosted applications.
Typically, a secure communication protocol is used during communication between peer devices, such as a client user device and a server hosting an application, to ensure that information can be exchanged without unauthorized third party interception or corruption of the signals. Transport Layer Security (TLS) is an industry standard protocol to provide confidentiality, authenticity and integrity of the data sent over an insecure public network. The TLS protocol can provide encryption, authentication, and data integrity services to applications running above it. Encryption is used obfuscate what is sent over a network between connection a client device and a server. Authentication is used to verify the validity of identification provided between the client device and the server. Integrity is used to detect message tampering and forgery. In order to establish a cryptographically secure data channel, the client device and the server are required to agree upon ciphersuites and keys to use to encrypt the data transmitted between them.
The TLS protocol specifies a handshake sequence to perform this exchange. A full TLS handshake uses public key cryptography (also known as asymmetric key cryptography), which allows the client device and the server to negotiate a shared secret key over an unencrypted channel without the need to establish any prior knowledge of each other. Both the client device and the server are permitted to authenticate their identity as part of the full TLS handshake. The TLS protocol also provides a message framing service that signs each message with a message authentication code (MAC). The MAC algorithm is a one-way cryptographic hash function having keys that are negotiated by the connection peers. A MAC value is generated for and appended to each TLS message that is sent. A receiver of the message can verify the MAC value to ensure message integrity.
FIG. 1 is an illustrative message flow diagram representing a typical full TLS handshake. Network Working Group, RFC 5507, Transport Layer Security (TLS) Session Resumption without Server-Side State, the Internet Society, January 2008, specifies the full TLS handshake message sequence. A TLS client sends an initial “client hello” message that lists cryptographic information such as the TLS version and, in the client's order of preference, the CipherSuites supported by the client. The message also contains a random byte string that is used in subsequent computations. The protocol allows for the “client hello” to include the data compression methods supported by the client. The initial client message includes an empty SessionTicket extension. The TLS server responds with a “server hello” message that contains a CipherSuite chosen by the server from the list provided by the client, a session ID, and another random, byte string. The server also sends its digital certificate. If the server requires a digital certificate for client authentication, the server sends a “client certificate request” message that includes a list of the types of certificates supported and the Distinguished Names of acceptable Certification Authorities (CAs). TLS client verifies the server's digital certificate. TLS client sends the random byte string that enables both the client and the server to compute the secret key to be used for encrypting subsequent message data. The random byte string itself is encrypted with the server's public key. If the TLS server sent a “client certificate request” message, the TLS client sends a random byte string encrypted with the client's private key, together with the client's digital certificate, or a “no digital certificate alert”. The TLS server verifies the client's certificate. TLS client sends the server a “finished” message, which is encrypted with the secret key, indicating that the client part of the handshake is complete. The TLS server sends the TLS client a “finished” message, which is encrypted with the secret key, indicating that the server part of the handshake is complete. For the duration of the TLS session, the TLS server and TLS client can now exchange messages that are symmetrically encrypted with the shared secret key.
The TLS client's inclusion of the empty SessionTicket extension in the “client hello” message indicates to the TLS server that it supports a mechanism to distribute encrypted session-state information to the TLS client in the form of a ticket. The extension is empty since the client does not already possess a ticket for the TLS server at the time of setting up an initial TLS connection. The TLS server sends an empty SessionTicket extension to indicate that it will send a new session ticket using a NewSessionTicket handshake message. If the TLS server wants to use this mechanism, it stores its session state (such as ciphersuite and master secret) to a TLS ticket that is encrypted and integrity-protected by a key known only to the TLS server. The ticket is distributed to the TLS client using a NewSessionTicket TLS handshake message. This message is sent during the full TLS handshake before the ChangeCipherSpec message, after the server has successfully verified the client's Finished message. The TLS client caches this ticket along with the master secret and other parameters associated with the current session. When the client wishes to resume the session, following an interruption, for example, it includes the ticket in the SessionTicket extension within the “client hello” message.
A full TLS handshake involves the TLS server using its private key to decrypt a pre-master secret that is encrypted by a client device using the TLS server public key. This decryption operation can be computationally expensive, i.e. require a larger number of processor cycles, since the keys used typically are quite long, e.g., 2048 bits. This results in communication latency while the TLS handshake is being completed. The TLS protocol specifies use of the TLS ticket to invoke an abbreviated TLS handshake that is less computationally expensive, and therefore incurs less latency, to establish a connection that resumes a TLS session between a TLS client device and a TLS server that was set up previously using a full TLS handshake but was interrupted.
FIG. 2 is an illustrative message flow diagram representing use of a typical abbreviated TLS handshake initiated with a TLS ticket. See, RFC 5077. To resume a session, the TLS client sends an initial “client hello” message that includes, in the SessionTicket extension, the encrypted ticket sent previously by the TLS server. The TLS server responds with a “server hello” message that contains the empty SessionTicket extension, a NewSessionTicket, a change cipher spec and a finished message. No key exchange is required, obviating the computationally intensive encryption activities and reducing latency. The TLS client responds with a ChangeCipherSpec message and a Finished message. The TLS server and TLS client now exchange messages that are symmetrically encrypted with the previously agreed upon shared secret key. Thus, by transmitting the ticket back to the server at the beginning of the next TLS connection both client device and the server can resume their previous session, without the need for a full TLS handshake.
The TLS protocol also specifies other extensions that can be used to enhance a TLS protocol exchange. For example, a Server Name Indicator (SNI) extension enables a client device browser to send the sever hostname that it intends to connect to. A Next Protocol Extension (NPN) lets both a client device and a server agree on the protocol to run inside an encrypted connection. These extensions may be included in a message, e.g., a “client hello” message, used to initiate a connection, for example.
A DDoS attack on a TLS server may involve an army of Botnet or Zombie computers sending bogus messages attempting to initiate TLS handshakes in an effort to overwhelm the TLS server, making it unavailable to legitimate TLS clients. A Distributed Denial of Service (DDoS) attack is an attempt to make an online service unavailable by overwhelming it with traffic from multiple sources. A DDoS attack typically uses many devices often distributed globally, and perhaps thousands of unique IP addresses, to flood a target with network requests. Some of the most serious attacks involve forging of IP sender addresses (IP address spoofing) so that the location of the attacking machines cannot easily be identified, nor can filtering be done based on the source address. The most common type of DDoS attack involves an attacker trying to do one of the following: (i) disrupt a legitimate user's connectivity by exhausting bandwidth, router processing capacity or network resources; these are essentially network/transport-level flooding attacks; or (ii) disrupt a legitimate user's services by exhausting the server resources (e.g., sockets, CPU, memory, disk/database bandwidth, and I/O bandwidth); these essentially include application-level flooding attacks. Today, DDoS attacks are often launched by a network of remotely controlled, well organized, and widely scattered Zombies or Botnet computers that are simultaneously and continuously sending a large amount of traffic and/or service requests to the target system. The target system either responds so slowly as to be unusable or crashes completely. See, S. T. Zargar, J. Joshi and D. Tipper, A Survey of Defense Mechanisms Against Distributed Denial of Service (DDoS) Flooding Attacks, IEEE Communications Surveys & Tutorials, (Accepted for publication), published online February 2013.